-
Notifications
You must be signed in to change notification settings - Fork 10.6k
CustomAvailability: synthesized dynamic availability checking function should be private #85549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@swift-ci please smoke test |
dcd7c04 to
3609030
Compare
|
@swift-ci please smoke test |
3609030 to
1d915ca
Compare
|
@swift-ci please smoke test |
604d160 to
496f1d1
Compare
|
@swift-ci please smoke test |
496f1d1 to
0eeaa96
Compare
|
@swift-ci please smoke test |
0eeaa96 to
59c08d3
Compare
|
@swift-ci please smoke test |
…n should be private When compiling a Swift module in incremental mode, each Swift source file is compiled into an object file and we use linker to link them together. Because the predicate function for checking dynamic feature availability is eagerly synthesized per compilation unit, the linker will complain about duplicated symbols for them. Setting their visibility as private ensures that linker doesn't see them, thus addressing the linker errors. One workaround for this problem is to enable WMO. rdar://164971313
59c08d3 to
d144524
Compare
|
@swift-ci please smoke test |
| funcDecl->setBodySynthesizer(synthesizeAvailabilityDomainPredicateBody, | ||
| (void *)var); | ||
| funcDecl->setAccess(AccessLevel::Internal); | ||
| funcDecl->setAccess(AccessLevel::Private); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why private rather than marking them as @export(implementation), which allows the linker to merge the different copies in different translation units?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we worry about deserialization issues trigged by the function body of this synthesized function when marked as @export(implementation)? Previously, we have been hitting a module deserialization error (e.g.rdar://164410957).
|
@swift-ci please smoke test Windows |
When compiling a Swift module in incremental mode, each Swift source file is compiled into an object file and we use linker to link them together. Because the predicate function for checking dynamic feature availability is eagerly synthesized per compilation unit, the linker will complain about duplicated symbols for them. Setting their visibility as private ensures that linker doesn't see them, thus addressing the linker errors.
One workaround for this problem is to enable WMO.
rdar://164971313